Modern software development is evolving away from the client-server model toward “cloud”-based processing systems that provide access to data and services via the Internet or other networks. In contrast to prior systems that hosted networked applications on dedicated server hardware, the cloud computing model provides applications over the network “as a service”. The cloud computing model can often provide substantial cost savings to the customer over the life of the application because the customer no longer needs to provide dedicated network infrastructure, electrical and temperature controls, physical security and other logistics in support of dedicated server hardware.
In particular, cloud-based architectures that simultaneously support multiple tenants have been developed to improve collaboration, integration and community-based improvement between tenants without sacrificing data security. Generally speaking, multi-tenancy refers to a system wherein a single hardware and software platform simultaneously supports multiple customers or other groups of users from a common data store. The shared platform in the multi-tenant architecture is usually designed to virtually partition data and operations so that each tenant works with a unique virtual application instance. The Force.com service available from salesforce.com of San Francisco, Calif., for example, provides an application-centric approach that abstracts the server hardware altogether and that allows multiple tenants to simultaneously yet securely implement a wide variety of applications that are accessible via the Internet or a similar network.
As noted above, multi-tenant application systems can allow users to access data and services that are associated with any number of different organizations. Often, these multi-tenant systems are developed with multiple server instances to provide redundancy, load balancing, geographic distribution and other benefits. In many cases, each server instance resides at a unique domain (or subdomain) on the Internet or another network. Sessions established with a server at a particular domain can be readily managed using, for example, conventional cookies that track hypertext transport protocol (HTTP) or other session information for connections within that domain. Conventional cookies, however, are generally limited because they are not typically accessible to sessions with other domains. If a particular client initially establishes a connection with a first server residing within a first domain, for example, a subsequent connection to a second server at a second domain would not typically be able to view or process information relating to the first session, since the second server resides in a separate domain. This can create any number of challenges in implementation. If the user accesses the same application hosted on different servers, for example, and/or if the same user accesses different applications hosted on different servers, it can be challenging to track the various connections across multiple domains or sub-domains of the application server.